The Internet enables a user of a client computer system to identify and communicate with millions of other computer systems located around the world. A client computer system can identify each of these other computer systems using a unique numeric identifier for that computer called an “IP address.” When a communication is sent from a client computer system to a destination computer system, the client computer system typically specifies the IP address of the destination computer system in order to facilitate the routing of the communication to the destination computer system. For example, when a request for a World Wide Web page (“web page”) is sent from a client computer system to a web server computer system (“web server”) from which that web page can be obtained, the client computer system typically includes the IP address of the web server.
In order to make the identification of destination computer systems more mnemonic, a Domain Name System (DNS) has been developed that translates a unique textual name for a destination computer system into the IP address for that computer. The textual name is called a “domain name.” For example, the domain name for a hypothetical computer system operated by Micron Electronics, Inc. (“Micron Electronics”) may be “comp23.MicronPC.com”. Using domain names, a user attempting to communicate with this computer system could specify a destination of “comp23.MicronPC.com” rather than the particular IP address of the computer system (e.g., 198.81.209.25).
In addition to making the identification of destination computer systems more mnemonic, domain names introduce a useful layer of indirection between the name used to identify a destination computer system and the IP address of that computer system. Using this layer of indirection, the operator of a particular computer system can initially associate a particular domain name with a first computer system by specifying that the domain name corresponds to the IP address of the first computer system. At a later time (e.g., if the first computer system breaks or must be replaced), its operator can “transfer” the domain name to a second computer system by then specifying that the domain name corresponds to the IP address of the second computer system.
The domain names in DNS are structured in a hierarchical, distributed database that facilitates grouping related domain names and computers, as well as facilitating the uniqueness of different domain names. In particular, as mentioned above, a particular domain name such as “MicronPC.com” may identify a specific host computer. However, the hierarchical nature of DNS also allows a domain name such as “MicronPC.com” to represent a domain including multiple other domain names each identifying computers (also referred to as “hosts”), either in addition to or instead of identifying a specific computer. FIG. 1A illustrates a hypothetical portion of the DNS database 100 in which the node representing the MicronPC.com domain name 110 is the root node in an MicronPC.com domain 150 that includes 7 other nodes each representing other domain names. Each of these domain names in the MicronPC.com domain can be, but do not have to be, under the control of a single entity (e.g., Micron Electronics). FIG. 1A also includes a HostPro.com domain 155 that includes a single domain name.
As is illustrated, the DNS database can be represented with a tree structure, and the full domain name for a given node in the tree can be determined by concatenating the name of each node along the path from the given node to the root node 101, with the names separated by periods. Thus, the 8 nodes in the MicronPC.com domain represent the domain names MicronPC.com 110, foo.MicronPC.com 112, bar.MicronPC.com 114, comp23.MicronPC.com 116, foo.foo.MicronPC.com 118, bar.foo.MicronPC.com 120, abc.comp23.MicronPC.com 122, and cde.comp23.MicronPC.com 124. Other domain names outside the MicronPC.com domain are also illustrated in FIG. 1A, including BCD-Corp.com 132 and HostPro.com 134 in the “.com” domain (whose boundary is not illustrated in FIG. 1A) and Stanford.edu 136 and Berkeley.edu 138 in the “.edu” domain (whose boundary is not illustrated in FIG. 1A). The hierarchical nature of the domain names also assist in maintaining uniqueness of names—for example, while the domain names for nodes 112 and 118 each have the same text label of “foo,” their full domain names are distinct.
The hierarchical, distributed structure of DNS additionally assists in the mapping of the textual domain names to the appropriate IP addresses. In particular, DNS is supported by a network of domain name server computer systems (“domain name servers”) distributed throughout the Internet that maintain mappings from domain names to IP addresses. For any particular domain name, at least one domain name server is designated as being authoritative for that particular domain name and can determine one or more IP addresses to which the particular domain name should be mapped. When another computer requests the one or more IP addresses for a domain name, an authoritative domain name server for that domain name can then make the appropriate IP addresses available to the requestor. A piece of software that is commonly used to implement the DNS protocols is the Berkeley Internet Name Domain (“BIND”) software, available at the time of this writing at “http://www.isc.org/products/BIND/”. This software assists authoritative domain name servers to maintain the appropriate mapping information for domain names, and also assists other computers in identifying the domain name servers that are authoritative for a domain name when needed.
Each domain name will have one authoritative name server that is designated as the primary master name server (“primary name server”) for that domain name, and the primary name server will have control over the stored information (including the IP addresses) for that domain name. In particular, the information about the domain name will typically be stored as a local file on the primary name server computer (called a “zone data file,” as discussed below), and the primary name server will thus control any changes that are to be made to the domain name information. If there are additional non-primary name servers that are authoritative for the domain name, these name servers are referred to as “slave name servers.” When a primary name server begins to execute, it typically reads the information from each zone data file that is stored and then caches that information in its memory for quick access. Slave name servers obtain their domain name information from the appropriate primary name server (typically when they begin to execute), and can then make the information available to requestors.
Rather than being associated directly with domain names, each name server is actually associated with one or more zones of domain names, with each zone including one or more related domain names. Various information about each zone is stored in a zone data file for that zone, including information indicating the primary name server for the zone, slave name servers for the zone, domain name-to-IP address mappings for each domain name in the zone, domain name aliases that represent other domain names in the zone, and a serial number indicating a version of the zone data file. A primary or slave name server for a zone can be a host computer associated with one of the domain names in the zone, or can instead be associated with a domain name located elsewhere in the DNS database hierarchy. Each entry in the zone data file is referred to as a DNS resource record.
FIG. 1B illustrates an example of the distinction between domains and zones. As discussed above, the MicronPC.com domain includes 8 domain names, but as is illustrated, this domain is divided up in this example into 3 different zones. In particular, the MicronPC.com zone 170 contains the MicronPC.com, comp23.MicronPC.com, abc.comp23.MicronPC.com, and cde.comp23.MicronPC.com domain names. The other 4 domain names have been assigned to different zones, with the bar.MicronPC.com domain name being located in the bar.MicronPC.com zone 165 and the other three domain names being located in the foo.MicronPC.com zone 160. Such zone divisions could be implemented for a variety of reasons, such as for ease of administration if the computers associated with the domain names in each of the zones are at different physical locations or are part of different organizations within the Micron Electronics. As described above, a primary name server for a zone can be a computer whose domain name is not within the zone. Thus, for example, while the MicronPC.com computer may be the primary name server for the MicronPC.com zone in FIG. 1B and the bar.MicronPC.com computer may be the primary name server for the bar.MicronPC.com zone, the HostPro.com computer could be the primary name server for the foo.MicronPC.com zone (and thus store the zone data file for the foo.MicronPC.com).
Thus, when a client computer wants to communicate with a computer supporting a domain name, the client can request the appropriate IP address for the domain name computer from one of the authoritative name servers for the zone that includes the domain name, and the name server can then provide the IP address to the client. However, in order to obtain information about a domain name, the client computer needs to be able to identify the authoritative name servers for the domain name. DNS resolves domain name requests in a hierarchical manner. One or more root name servers maintain information about the authoritative name servers for each of the top-level domains (e.g., “.com” and “.edu”). Those authoritative name servers can then provide information about the authoritative name servers for domains at a next level lower in the hierarchy—for example, an authoritative name server for the “.com” domain will know the authoritative name servers for the MicronPC.com domain. Continuing in this hierarchical manner, the authoritative name servers for the domain name of interest can be identified.
Each name server maintains information on each of the zones for which it is the primary name server or a slave name server. In particular, most name servers maintain a configuration file that lists each zone and the zone data file for that zone. FIG. 2A provides one example of a configuration file for the name server that is the primary name server for the foo.MicronPC.com zone, as is indicated in line 205 of the file. As is shown in the first DNS configuration record, the zone data file for the foo.MicronPC.com is named “db.foo.MicronPC”. The name server is also shown to be the primary name server for the stanford.edu zone in the second DNS configuration record. Thus, when this name server begins to execute, it will read each of the listed zone data files to obtain the zone information for its zones. Those skilled in the art will appreciate that different formatting may be used for the configuration file in different situations, such as for different versions of the BIND software.
FIG. 2B illustrates an example of a possible db.foo.MicronPC zone data file for the foo.MicronPC.com zone. As those skilled in the art will appreciate, the second and third DNS resource records in the zone data file indicate that a computer with lo the domain name ns1.HostPro.com (not illustrated in FIGS. 1A and 1B) is the primary name server for the foo.MicronPC.com zone and that a computer with the bar.foo.MicronPC.com domain name is a slave name server, and other DNS resource records include a variety of other information about the foo.MicronPC.com zone.
As mentioned above, an authoritative name server for a zone maintains information on the authoritative name servers for subzones of the zone. Thus, the authoritative name servers for the MicronPC.com zone need to maintain information to allow them to delegate requests about the foo.MicronPC.com subzone to the primary and slave name servers for the subzone, ns1.HostPro.com and bar.foo.MicronPC.com respectively. The zone data file for the MicronPC.com zone could include the additional entries illustrated in FIG. 2C to delegate requests about the foo.MicronPC.com zone to the ns1.HostPro.com and bar.foo.MicronPC.com domain names.
In addition to the technical information that is present in the zone data files, additional administrative information is also maintained for some domain names by the registrars for those domain names. This administrative information, also referred to as “whois data” or a DNS whois record, identifies the current administrative contact for the domain name, and can include additional information such as the “registrant” (i.e., owner) of the domain name, when the domain name was first created and when the administrative information was last modified. A registrar is a company that assigns new domain names to applicants and registers the new domain names in a central registry. If a registrar for a new domain name also acts as the primary name server for a zone including that domain name, the registrar will maintain for that domain name both the technical DNS information in its zone data file and the administrative whois DNS information.
Additional details about DNS and the BIND software are available in “DNS and BIND, Third Edition” by Paul Albitz & Cricket Liu, 1998, O'Reilly & Associates Publishing, Sebastopol, Calif. 95472, which is hereby incorporated by reference in its entirety.
As described above, a computer with a domain name that is outside of a zone can serve as a primary name server for the zone. In fact, a company such as web to hosting company HostPro, Inc. (“HostPro”) may provide a service to other companies in which a HostPro computer will serve as the primary name server for a zone having domain names that are mapped to computers controlled by those other companies (e.g., computers that are located at those companies' sites). Alternately, HostPro may perform a similar service as a primary name server for a zone with domain names for another company that are mapped to computers that are controlled by HostPro (e.g., computers that are located at a HostPro site). In either situation, as the primary name server, the HostPro computer would store and maintain a zone data file for the zone. A company such as HostPro could also provide a variety of types of services to other companies, such as web hosting services (e.g., providing disk space for the company's web pages or processing capabilities to handle requests for those web pages), email hosting services (e.g., providing processing capabilities to forward email that is received for the domain or disk space to store received email messages), application service provider services (e.g., providing disk and processing capabilities to execute an application on behalf of a another device such as a client computer of the company), connectivity service (e.g., an Internet Service Provider (ISP) that provides access to the Internet), etc. In addition, HostPro could serve as a registrar that registers domain names for other companies.
Unfortunately, DNS information can change frequently, and various problems exist with updating the necessary records to ensure that up-to-date information is provided in response to requests. One way in which DNS information changes is that users (e.g., system administrators) may often want to make changes to information in an existing zone data file. These changes could be to modify any of the information in the zone data file, such as to add information about new domain names added to the zone, to remove information about domain names removed from the zone, to change a name server for the zone, or to change other configuration information for the zone. Alternately, the user may wish to change the IP address to which a domain name is mapped. Even if the user has control over the primary name server for the zone and can directly edit the zone data file, the strict formatting requirements for zone data files can make the revision process error-prone. The situation is exacerbated when the user does not have control over the zone data file (e.g., the primary name server computer is located remotely or is under the control of another entity), and must send requests for changes to some other user.
In addition to modifying existing zone data files, DNS information for a primary name server can change when zone data files are added or removed. This can occur frequently for some primary name servers. For example, a primary name server that is maintained by a registrar for other companies may get a new zone data file for every company that registers one or more domain names with the registrar. In addition, companies that already have a registered domain name may change the company that is responsible for managing their domain name, thus causing the primary name server for the zone containing their domain name to change. When these types of changes occur, the primary name servers need to have their information modified so that they provide appropriate up-to-date information to requests. In addition, other computers (e.g., root name servers for the DNS database) need to have their information updated so that they can identify the primary name server for a newly created domain name or a domain name being managed by a new company.
While changes to zone information and zone data files can frequently occur, these changes create problems for primary name servers. In particular, as noted above, a primary name server generally reads its zone data files at startup, and then uses the information stored in memory. Thus, changing data in a zone data file or adding a new zone data file will not necessarily cause the primary name server to be aware of the new information—in some situations, the primary name server will not detect the new information until the primary name server is halted and restarted. In other situations, the primary name server may check for changes to its zone data files only occasionally, such as once a day. Thus, while changes to a zone data file may have been made or new zone data files may have been added, such as to reflect physical changes that have occurred in the network, the changed information may not be used by the primary and slave name servers for a lengthy period of time. This means that the domain name information being provided by the authoritative name servers may not reflect the physical reality of the computers on the Internet (e.g., if a computer to whom a domain name was previously mapped is no longer available, or a computer mapped to a new domain name is available but requesters cannot determine that a computer for the domain name is available).
One possible solution to the delay in primary name servers becoming aware of the changes to their zone data files is for primary and slave name servers to not cache zone data file information in memory. In this situation, each time that one of the primary or slave name servers receives a request for zone information contained in one of the zone data files, the primary name server would read the appropriate zone data file to retrieve the information. Unfortunately, the amount of time required to read a zone data file from a hard disk is so long that this solution is not workable.
Another possible solution to the delay in primary name servers becoming aware of the changes to their zone data files is for a primary name server to periodically update its cached information in memory. In particular, at regular intervals the primary name server could obtain the current zone information in its zone data files in one of several ways, such as by re-reading each zone data file, or by checking each zone data file to see if it has changed (e.g., by reading a file to determine if the serial number of the file has changed, or by accessing information about the time of the last modification of the file) and then re-reading only those changed files. Similarly, in order to detect new zone data files, the primary name server could re-read its configuration file and compare it to a previous version or to cached information in order to determine if a currently listed zone data file has not been read or if a previously read zone data file is no longer listed. A problem with this solution is that during this process of updating the zone information, the primary name server is not available to respond to requests about the zone information, and thus a client computer attempting to access a domain name in the zone may be unable to contact the available computer for that domain name because the client cannot determine the appropriate IP address for the computer. Despite this problem with lack of availability, re-reading of zone data file information may be used by primary name servers with a very small number of zone data files (e.g., less than 10) as the least problematic solution to the problem of changing DNS information.
Unfortunately, this re-reading of zone data file information from the configuration file and zone data files becomes increasingly unworkable as the number of zone data files associated with a primary name server increases. Moreover, some primary name servers can have very large numbers of associated zone data files, ranging from thousands to even millions of such zone data files. However, a primary name server trying to re-read zone data file information for such large numbers of zone data files may take 15-30 minutes or even longer to perform this task, with the primary name server unable to respond to domain name mapping requests or other zone information requests during that time. One example of a primary name server having a very large number of associated zone data files would be one maintained by a company such as HostPro that acts as a registrar or provides some type of zone management or hosting service for other companies. For example, the register.com company (www.register.com) currently indicates that it has registered over 1 million domain names for other companies.
Thus, a need exists for a way that primary name servers can more efficiently and rapidly detect and incorporate changes to zone information in their zone data files. In addition, there is a need to provide an easy way for users to modify DNS information for their domain names, particularly when the information is maintained by a computer that is not under their direct control.